TCP is a transport protocol in the internet protocol suite (see for example, the publication by W. R. Stevens, ‘TCP/IP illustrated, Volume 1: The protocols’, Addison-Wesley, Reading, Mass., November 1994). It is used in applications such as telnet FTP (File Transfer Protocol) and HTTP (HyperText Transfer Protocol). TCP is designed for wire networks which have very low error rates.
Flow control in TCP is governed by two windows: the sender's congestion window (‘cwnd’) and the receiver's advertised window (‘awnd’). Flow control is based on the minimum of these 2 windows. The ‘cwnd’ is modified dynamically to match the capacity in the network. Most importantly it is reduced whenever packets are lost as this is an indication of congestion in the network. The ‘awnd’ is based on the receiver's ability to buffer data that it receives and it can be dynamically reduced if the receiver is unable to cope with the rate of reception of data. The initial value of ‘awnd’ is controlled by parameters configured in the TCP protocol stack.
As mentioned above, TCP is designed for low error rate networks. Therefore any packet losses which occur in TCP are regarded as due to network congestion and are therefore followed by a reduction in ‘cwnd’ and consequently in the data rate of the sender as mentioned above. However, this is not appropriate to wireless networks which are inherently high error rate systems. Therefore, the 3GPP (3rd Generation Partnership Project) standard provides ARQ (Automatic Repeat Request) functionality, known as RLC (Radio Link Control—see, for example, the 3GPP technical specification 3GPP TS 25.322) that allows packets to be re-transmitted which have been subjected to error due to transmission over the air interface. However, the use of ARQ schemes result in the packets arriving out of order, so they have to be buffered before they can be passed on to TCP. The use of buffering introduces increased delay and this can result in increased RTT (Round Trip Time).
Assuming that the highest rate services are provided in the downlink, this means that large buffering is likely to be required in the network node, i.e., the RNC (Radio Network Controller) in the case of 3GPP systems. The following considers this downlink (DL) problem. However the present invention is also appropriate for controlling uplink TCP flows.
The maximum DL rate specified in the 3GPP technical specification 3GPP TS 34.108 is 2 Mbps. Assuming that it is not possible to alter the TCP protocol stack at the receiver (i.e., UE), it is therefore necessary that the UE must advertise a window at least equal to the bandwidth delay product appropriate for the 2 Mbps service. If the UE is to support the maximum rate of 2 Mbps then the advertised window must be extremely large. If a smaller rate is then provided to the UE (due, for example, to the fact that many UE's are requesting service at the same time) then buffer overflow might occur. If buffer overflow does not occur the round trip time (RTT) will be very high since data will spend a long time buffered at the network node.
High RTT will have a negative impact on performance perceived by the user. This is particularly true in the case of the user wishing to continue web browsing while downloading a large file via FTP; the web browsing session will appear to be extremely slow. Therefore we wish to provide a flow control technique to maintain a target RTT for any rate provided by the network while maintaining the ability to download data at rates up to the maximum 2 Mbps rate.
As mentioned previously, flow control is provided by the sender's ‘cwnd’ and the receiver's ‘awnd’. Since control of the sender's ‘cwnd’ resides in the server, it can be located remotely and is not in any way controllable. It is therefore necessary that flow control is provided by the ‘awnd’.
A number of schemes (discussed briefly below) for flow control have been suggested for TCP over 3G wireless systems. However, the issue with which these are most concerned is preventing the buffer at the network node from overflowing (i.e., the sending node in the case of data download).
In the publication by Koga, Kawahara and Oie, “TCP flow control using link layer information in mobile networks”, Proceedings of SPIE Conference of Internet Performance and Control of Network Systems III, Boston, Mass. 7, 2002, it is proposed that the receiver, i.e., the UE in the most likely case of file download, modifies the TCP window that it advertises based not on the capacity of the receivers buffers as is conventionally the case but on measures obtained from the RLC. This approach is extremely problematic since it means modification of the TCP protocol stack at the UE and it may not be possible to obtain control of this stack. This is particularly true in the case where a PC (Personal Computer) is connected to a UE (which acts effectively as a modem) and the TCP protocol stack resides in the PC.
The publication by Seok, Joo and Kang, “A-TCP: A mechanism for improving TCP performance in wireless environments”, IEEE broadband wireless summit, May 2001 suggests a scheme whereby two entirely split connections are made, one between the server and the network node and another between the network node and the UE. This requires considerable additional complexity and may not be of any benefit for transfers using UDP (User Datagram Protocol).
The publication by Bakre and Badrinth, “I-TCP: indirect TCP for mobile hosts”, Proceedings of the 15th International conference on distributed computer systems, May 1995, suggests modifying the TCP window size in TCP ACKs (ACKnowledge packets). However in this publication the goal is simply to modify the TCP window size to the available buffer size at the network node. Limiting the buffer occupancy as in this publication does not guarantee a specified RTT.
A need therefore exists for method and arrangement for TCP flow control wherein the abovementioned disadvantage(s) may be alleviated.